<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<link rel="stylesheet" type="text/css" href="css.css">
<TITLE>Sanewall, Configuration tutorial</TITLE>
<meta name="author" content="Costa Tsaousis">
<meta name="robots" content="noindex">
<meta name="description" content="

Home for sanewall, an iptables stateful packet filtering firewall builder for Linux (kernel 2.4),
supporting NAT, SNAT, DNAT, REDIRECT, MASQUERADE, DMZ, dual-homed, multi-homed and router setups,
protecting and securing hosts and LANs in all kinds of topologies. Configuration is done using
simple client and server statements while it can detect (and produce) its configuration
automatically. Sanewall is extremely easy to understand, configure and audit.

">

<meta name="keywords" content="iptables, netfilter, filter, firewall, stateful, port, secure, security, NAT, DMZ, DNAT, DSL, SNAT, redirect, router, rule, rules, automated, bash, block, builder, cable, complex, configuration, dual-homed, easy, easy configuration, example, fast, features, flexible, forward, free, gpl, helpme mode, human, intuitive, language, linux, masquerade, modem, multi-homed, open source, packet, panic mode, protect, script, service, system administration, wizard">
<meta http-equiv="Expires" content="Wed, 19 Mar 2003 00:00:01 GMT">
</HEAD>

<BODY bgcolor="#FFFFFF">

<p>

Since R5 v1.97 of sanewall there is the command line argument <b>helpme</b> that will try to guess
your configuration on the running machine. To use it, simply run:<p>

<b>/etc/init.d/sanewall helpme &gt;/tmp/sanewall.conf</b> <font color="gray">(installed from RPM)</font>, or
<p>
<b>sanewall.sh helpme &gt;/tmp/sanewall.conf</b> <font color="gray">(installed from .tar.bz2)</font>
<p>
The purpose of the <b>helpme</b> feature is to give you a configuration file that you can modify to get an
operational firewall quickly, especially if your firewalling and iptables knowledge is limited. This feature
does not stop or alter the running firewall of your machine.
<p>
Bellow is the procedure you should follow to manually design a secure sanewall firewall.
<p>
<table border=0 cellpadding=10 cellspacing=0 width="100%">
<tr><td bgcolor="#EEEEEE"><b>1. Identify all the network interfaces your firewall host has</td></tr></table>
<br>
Network interfaces are there for some reason. You have to do something about all the interfaces of your host.
If you don't do something at the firewall level with a network interface, then it depends of the firewall policy what will happen
with traffic on this interface. By default sanewall will <b>drop</b> all traffic coming in and going out via an undefined network interface,
so the network interface will have no meaning to be up and running. This is a common mistake on some ADSL configurations, where users
ignore the loop device that connects the linux router with the ADSL device.
<p>
To identify your network interfaces use the <b>ip link show</b> command. The example bellow shows my home router <b>ip link show</b> output:

<center><table border=0 cellpadding=15 cellspacing=20 width="70%">
<tr><td bgcolor="#F0F0F0">
<b><pre><font color="gray">
[root@gateway /]# ip link show
1: <font color="red">lo</font>: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: <font color="red">eth0</font>: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:50:fc:21:9a:ab brd ff:ff:ff:ff:ff:ff
12: <font color="red">ppp0</font>: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 3
    link/ppp
</font></pre></b>
</td></tr>
</table>
</center>

There are a few important thinks to always remember:<p>
<ul>
	<li><b>lo</b> exists on all machines and is used for communication between programs running on this machine.
	Sanewall handles this automatically. You don't have to do anything about <b>lo</b>.
	<br>&nbsp;
	</li>
	<li>Network interfaces (except the <b>lo</b> interface) are used for two purposes:
	<br>&nbsp;
	<ul>
		<li>By the firewall host for its own communication with the rest of the world. This is the case when the
		firewall host requests something from some other host (a DNS lookup may be) for its own needs, or when
		some other host requests something from the firewall host, when the later is running some daemons (servers) too.
		<br>&nbsp;
		</li>
		<li>By other hosts as <b>gateways</b> in order to reach other hosts behind the firewall host.
		In this case, the firewall host simply passes traffic from one of its network interfaces to another.
		This is also called <b>routing</b>.
		<br>&nbsp;
		</li>
	</ul>
</ul>
In the above example, it is clear that I have two network interfaces (except <b>lo</b>): <b>eth0</b> and <b>ppp0</b>.
<p>
One extra step is to identify if the network interfaces appearing here might dynamically change during run-time.
For example my <b>ppp0</b> might become <b>ppp1</b> or <b>ppp2</b> in certain cases. To overcome this problem, I can
say that my link to the outside world is not <b>ppp0</b> but <b>ppp+</b>. The plus character matches all the interfaces
that <b>begin</b> with the text given before the plus sign. In this case, it matches all the possible network interfaces
that start with <b>ppp</b>.
<p>
Keep in mind that sanewall (and iptables) does not really care if the interface defined in a firewall actually exists or not.
This means that you can setup firewalls on interfaces that might become available later or altered during run time.
This also means that if you define an interface with a wrong name, sanewall and iptables will not complain.
<p>

<table border=0 cellpadding=10 cellspacing=0 width="100%">
<tr><td bgcolor="#EEEEEE"><b>2. Give a role to each interface identified</td></tr></table>
<br>
Now I have to assign a role to each network interface, i.e. what is the function of each of those interfaces?<br>
For this, I create a table similar to the one bellow. It is important to focus on the <u>REQUESTS</u>; forget the replies.

	<center>
	<table border=0 cellpadding=3 cellspacing=5 width="70%">
	<tr><th bgcolor="#000000"><font color="white">interface</th><th bgcolor="#000000"><font color="white">description</th><th bgcolor="#000000"><font color="white">incoming&nbsp;requests</th><th bgcolor="#000000"><font color="white">outgoing&nbsp;requests</th><th bgcolor="#000000"><font color="white">routing&nbsp;requests&nbsp;in</th><th bgcolor="#000000"><font color="white">routing&nbsp;requests&nbsp;out</th></tr>
	<tr>	<td align="center"><b>eth0</td>
		<td>My home LAN</td>
		<td>Many services from my LAN workstations (i.e. dns, ftp, samba, squid, dhcp, http, ssh, icmp)</td>
		<td>A few services my LAN workstations provide (i.e. samba, icmp)</td>
		<td>All LAN workstations requests going to the internet</td>
		<td>Nothing</td>
		</tr>
	<tr bgcolor="#F0F0F0">	<td align="center"><b>ppp+</td>
		<td>The Internet</td>
		<td>I run a public mailer, a public web server and a public ftp server for my domain</td>
		<td>All the services my Linux could ask from the internet</td>
		<td>Nothing</td>
		<td>All LAN workstations requests going to the internet</td>
		</tr>
	</table>
	</center><p>

Keep in mind that:
<p>
<ul>
	<li><b>incoming requests</b> represent <b>servers</b> running on the firewall host.<br>&nbsp;</li>
	<li><b>outgoing requests</b> represent <b>clients</b> running on the firewall host.<br>&nbsp;</li>
	<li><b>routing requests in</b> represent <b>clients</b> on hosts at the network interface in question.<br>&nbsp;</li>
	<li><b>routing requests out</b> represent <b>servers</b> on hosts at the network interface in question.<br>&nbsp;</li>
</ul>

So, the above could also be presented as:

	<center>
	<table border=0 cellpadding=3 cellspacing=5 width="70%">
	<tr><th bgcolor="#000000"><font color="white">interface</th><th bgcolor="#000000"><font color="white">name</th><th bgcolor="#000000"><font color="white">servers</th><th bgcolor="#000000"><font color="white">clients</th><th bgcolor="#000000"><font color="white">routing&nbsp;clients</th><th bgcolor="#000000"><font color="white">routing&nbsp;servers</th></tr>
	<tr>	<td align="center"><b>eth0</td>
		<td align=center>home</td>
		<td align=center>dns, ftp, samba, squid, dhcp, http, ssh, icmp</td>
		<td align=center>samba, icmp</td>
		<td align=center>all</td>
		<td align=center>none</td>
		</tr>
	<tr bgcolor="#F0F0F0">	<td align="center"><b>ppp+</td>
		<td align=center>internet</td>
		<td align=center>smtp, http, ftp</td>
		<td align=center>all</td>
		<td align=center>none</td>
		<td align=center>all</td>
		</tr>
	</table>
	</center><p>


<table border=0 cellpadding=10 cellspacing=0 width="100%">
<tr><td bgcolor="#EEEEEE"><b>3. Create the sanewall configuration structure</td></tr></table>
<br>
Now that you have a list of all the interfaces and their roles, it is time to start writing the sanewall configuration file.
<p>
First write one interface statement for each network interface you identified above:

<center><table border=0 cellpadding=15 cellspacing=20 width="70%">
<tr><td bgcolor="#F0F0F0">
<b><pre><font color="red">
	version 5

	interface eth0 home


	interface ppp+ internet


</font></pre></b>
</td></tr>
</table>
</center>
<p>
Now, we can add the servers for each interface (based on the table above). Remember that these servers are all running on the firewall host:

<center><table border=0 cellpadding=15 cellspacing=20 width="70%">
<tr><td bgcolor="#F0F0F0">
<b><pre><font color="gray">
	version 5

	interface eth0 home<font color="red">
		server dns	accept
		server ftp	accept
		server samba	accept
		server squid	accept
		server dhcp	accept
		server http	accept
		server ssh	accept
		server icmp	accept
	</font>
	interface ppp+ internet<font color="red">
		server smtp	accept
		server http	accept
		server ftp	accept
	</font>
</font></pre></b>
</td></tr>
</table>
</center>
Now, we can add the clients for each interface. Remember that these clients are all running on the firewall host:

<center><table border=0 cellpadding=15 cellspacing=20 width="70%">
<tr><td bgcolor="#F0F0F0">
<b><pre><font color="gray">
	version 5

	interface eth0 home
		server dns	accept
		server ftp	accept
		server samba	accept
		server squid	accept
		server dhcp	accept
		server http	accept
		server ssh	accept
		server icmp	accept
		<font color="red">
		client samba	accept
		client icmp	accept
		</font>

	interface ppp+ internet
		server smtp	accept
		server http	accept
		server ftp	accept
		<font color="red">
		client all	accept
		</font>
</font></pre></b>
</td></tr>
</table>
</center>
<p>
At this point, everyone should be able to inter-operate correctly with the firewall host, but still we don't route any traffic.
This means that the linux box can "see" all the workstations on the LAN and these workstations can "see" the linux box, also that
the linux box can "see" the Internet and the Internet can "see" the servers of the ppp+ interface of the linux box, but the LAN
workstations cannot "see" the Internet.
<p>
It is now time to setup routing. To do this we will have to define a set of routers for all the interface combinations. This means
that if we have two interfaces we will have to define two routers. If we have 3 interfaces, we will have to define 6 routers, and
so on.

<center><table border=0 cellpadding=15 cellspacing=20 width="70%">
<tr><td bgcolor="#F0F0F0">
<b><pre><font color="gray">
	version 5

	interface eth0 home
		server dns	accept
		server ftp	accept
		server samba	accept
		server squid	accept
		server dhcp	accept
		server http	accept
		server ssh	accept
		server icmp	accept

		client samba	accept
		client icmp	accept


	interface ppp+ internet
		server smtp	accept
		server http	accept
		server ftp	accept

		client all	accept

	<font color="red">
	router home2internet inface eth0 outface ppp+


	router internet2home inface ppp+ outface eth0

	</font>
</font></pre></b>
</td></tr>
</table>
</center>
<p>
Remember that <a href="commands.html#inface">inface</a> and <a href="commands.html#outface">outface</a> match the <u>requests</u>,
not the replies. This means that the router <b>home2internet</b> matches all requests originated from eth0 and going out to ppp+
(and of course their relative replies in the opposite direction), while the router <b>internet2home</b> matches all the requests from the Internet to the
home LAN (and their relative replies back).
<p>
Now, based on the roles table of the previous section we see that we should route all requests coming in from eth0 and going out to
ppp+, and do not route any request coming from the internet and going out to the home LAN. Here it is:

<center><table border=0 cellpadding=15 cellspacing=20 width="70%">
<tr><td bgcolor="#F0F0F0">
<b><pre><font color="gray">
	version 5

	interface eth0 home
		server dns	accept
		server ftp	accept
		server samba	accept
		server squid	accept
		server dhcp	accept
		server http	accept
		server ssh	accept
		server icmp	accept

		client samba	accept
		client icmp	accept


	interface ppp+ internet
		server smtp	accept
		server http	accept
		server ftp	accept

		client all	accept


	router home2internet inface eth0 outface ppp+
		<font color="red">route all accept</font>


	router internet2home inface ppp+ outface eth0


</font></pre></b>
</td></tr>
</table>
</center>
<p>
<b>This is it. We are done! (for the filtering part of the firewall. Look bellow for setting up NAT too.)</b>
<p>
<table border=0 cellpadding=10 cellspacing=0 width="100%">
<tr><td bgcolor="#EEEEEE"><b>4. Optimizing the firewall</td></tr></table>
<br>
To save typing time, you can use this:

<center><table border=0 cellpadding=15 cellspacing=20 width="70%">
<tr><td bgcolor="#F0F0F0">
<b><pre><font color="gray">
	version 5

	interface eth0 home<font color="red">
		server "dns ftp samba squid dhcp http ssh icmp"	accept
		client "samba icmp"				accept
	</font>

	interface ppp+ internet<font color="red">
		server "smtp http ftp"	accept</font>
		client all		accept


	router home2internet inface eth0 outface ppp+
		route all accept
</font></pre></b>
</td></tr>
</table>
</center>
<p>
Note that we can remove any router statements not having any rules in them, so the <b>internet2home</b> router has been eliminated.
<p>
We might want to have extra checks on each interface to prevent spoofing. To find the IPs of your network interfaces use
<b>ip addr show</b> and to find the IP networks behind each interface use <b>ip route show</b>.

<center><table border=0 cellpadding=15 cellspacing=20 width="70%">
<tr><td bgcolor="#F0F0F0">
<b><pre><font color="gray">
	version 5
	<font color="red">
	# The network of our eth0 LAN.
	home_ips="195.97.5.192/28"
	</font>
	interface eth0 home <font color="red">src "${home_ips}"</font>
		server "dns ftp samba squid dhcp http ssh icmp"	accept
		client "samba icmp"				accept


	interface ppp+ internet <font color="red">src not "${home_ips} ${UNROUTABLE_IPS}"</font>
		server "smtp http ftp"	accept
		client all		accept


	router home2internet inface eth0 outface ppp+
		route all accept
</font></pre></b>
</td></tr>
</table>
</center>
<a href="commands.html#UNROUTABLE_IPS">UNROUTABLE_IPS</a> is a variable defined by sanewall and contains all the IPs that should not
be routed on the internet.
<p>
If home LAN did not had real IP addresses, we would have to add a <a href="commands.html#masquerade">masquerade</a> command in our
router:

<center><table border=0 cellpadding=15 cellspacing=20 width="70%">
<tr><td bgcolor="#F0F0F0">
<b><pre><font color="gray">
	version 5

	# The network of our eth0 LAN.
	home_ips="195.97.5.192/28"

	interface eth0 home src "${home_ips}"
		server "dns ftp samba squid dhcp http ssh icmp"	accept
		client "samba icmp"				accept


	interface ppp+ internet src not "${home_ips} ${UNROUTABLE_IPS}"
		server "smtp http ftp"	accept
		client all		accept


	router home2internet inface eth0 outface ppp+
		<font color="red">masquerade</font>
		route all accept
</font></pre></b>
</td></tr>
</table>
</center>
The <a href="commands.html#masquerade">masquerade</a> command sets up itself on the <b>outface</b> of a router.
<p>
We can now protect our ppp interface even further. For this we use the <a href="commands.html#protection">protection</a> command:

<center><table border=0 cellpadding=15 cellspacing=20 width="70%">
<tr><td bgcolor="#F0F0F0">
<b><pre><font color="gray">
	version 5

	# The network of our eth0 LAN.
	home_ips="195.97.5.192/28"

	interface eth0 home src "${home_ips}"
		server "dns ftp samba squid dhcp http ssh icmp"	accept
		client "samba icmp"				accept


	interface ppp+ internet src not "${home_ips} ${UNROUTABLE_IPS}"
		<font color="red">protection strong 10/sec 10</font>
		server "smtp http ftp"	accept
		client all		accept


	router home2internet inface eth0 outface ppp+
		masquerade
		route all accept
</font></pre></b>
</td></tr>
</table>
</center>
<p>
It could be nice if instead of dropping wrong packets originated from the Ethernet, to reject them so that our workstations
will not have to timeout if we do something that is not allowed. To do this we use the <a href="commands.html#policy">policy</a>
command:

<center><table border=0 cellpadding=15 cellspacing=20 width="70%">
<tr><td bgcolor="#F0F0F0">
<b><pre><font color="gray">
	version 5

	# The network of our eth0 LAN.
	home_ips="195.97.5.192/28"

	interface eth0 home src "${home_ips}"
		<font color="red">policy reject</font>
		server "dns ftp samba squid dhcp http ssh icmp"	accept
		client "samba icmp"				accept


	interface ppp+ internet src not "${home_ips} ${UNROUTABLE_IPS}"
		protection strong 10/sec 10
		server "smtp http ftp"	accept
		client all		accept


	router home2internet inface eth0 outface ppp+
		masquerade
		route all accept
</font></pre></b>
</td></tr>
</table>
</center>
<p>
Some servers on the Internet try to <b>ident</b> back the client to find information about the user requesting the service.
With our current firewall, such servers will have to timeout before accepting our request. To speed thinks up we could write:

<center><table border=0 cellpadding=15 cellspacing=20 width="70%">
<tr><td bgcolor="#F0F0F0">
<b><pre><font color="gray">
	version 5

	# The network of our eth0 LAN.
	home_ips="195.97.5.192/28"

	interface eth0 home src "${home_ips}"
		policy reject
		server "dns ftp samba squid dhcp http ssh icmp"	accept
		client "samba icmp"				accept


	interface ppp+ internet src not "${home_ips} ${UNROUTABLE_IPS}"
		protection strong 10/sec 10
		server "smtp http ftp"	accept

		<font color="red">server ident reject with tcp-reset</font>

		client all		accept


	router home2internet inface eth0 outface ppp+
		masquerade
		route all accept

	<font color="red">
	router internet2home inface ppp+ outface eth0
		route ident reject with tcp-reset
	</font>
</font></pre></b>
</td></tr>
</table>
</center>
Note that we now have added the router we eliminated above, since we need to add a service to it.<p>
The whole routing schema could be rewritten as:

<center><table border=0 cellpadding=15 cellspacing=20 width="70%">
<tr><td bgcolor="#F0F0F0">
<b><pre><font color="gray">
	version 5

	# The network of our eth0 LAN.
	home_ips="195.97.5.192/28"

	interface eth0 home src "${home_ips}"
		policy reject
		server "dns ftp samba squid dhcp http ssh icmp"	accept
		client "samba icmp"				accept


	interface ppp+ internet src not "${home_ips} ${UNROUTABLE_IPS}"
		protection strong 10/sec 10
		server "smtp http ftp"	accept

		server ident reject with tcp-reset

		client all		accept

	<font color="red">
	router internet2home inface ppp+ outface eth0
		masquerade reverse
		client all	accept
		server ident	reject with tcp-reset
	</font>
</font></pre></b>
</td></tr>
</table>
</center>
Now we have elicited the first router, but we defined everything in the second. We have used the <b>reverse</b> keyword in
<a href="commands.html#masquerade">masquerade</a> to make it set up in <b>inface</b> this time.<p>
We could use the first router (home2internet) to do everything, but then the client and server commands would need be reversed
(server all, client ident) which would be confusing.

<p>
<hr noshade size=1>
<table border=0 width="100%">
<tr><td align=center valign=middle>
	<A href="http://sourceforge.net"><IMG src="http://sourceforge.net/sflogo.php?group_id=58425&amp;type=5" width="210" height="62" border="0" alt="SourceForge Logo"></A>
</td><td align=center valign=middle>
	<b>Sanewall</b>, a firewall for humans...<br>
	&copy; Copyright 2004
	Costa Tsaousis <a href="mailto: costa@tsaousis.gr">&lt;costa@tsaousis.gr&gt</a>
</body>
</html>
